Support iproto feature discovery #243
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
DifferentialOrange
force-pushed
the
DifferentialOrange/gh-206-feature-discovery
branch
from
993f9ef to
f48099f
Compare
DifferentialOrange
requested review from
oleg-jukovec and
GRISHNOV
and removed request for
oleg-jukovec
Modern Tarantool documentation uses IPROTO_REQUEST_TYPE name for request type instead of IPROTO_CODE [1]. 1. https://www.tarantool.io/en/doc/latest/dev_guide/internals/box_protocol/ Part of #206
Modern Tarantool documentation uses hexadecimal codes for request codes [1]. 1. https://www.tarantool.io/en/doc/latest/dev_guide/internals/box_protocol/ Part of #206
Provide explicit handles to extract DatabaseError exceptions properties. Before this patch, one could extract Tarantool error code only through internal `args` property. Unfortunately, current exceptions API is inconsistent. Code uses `DatabaseError(code, message)`, `NetworkError(message)` and `NetworkError(exc)`, while NetworkError is a child class of DatabaseError. This patch shouldn't break current behavior. Part of #206
Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send the schema version and supported features and receive server-side schema version and supported features information to tune its behavior. After this patch, the request would be send on `connect`. Connector will use protocol version that is minimal of connector version (now it's 3) and server version. Feature would be enabled if both client and server supports it (for now client does not support any features from the list). Unknown request type error response is expected for pre-2.10.0 versions. In this case, protocol version would be `None` and no features would be enabled. 1. tarantool/tarantool#6253 Closes #206
DifferentialOrange
force-pushed
the
DifferentialOrange/gh-206-feature-discovery
branch
from
f48099f to
8024a1d
Compare
DifferentialOrange
deleted the
DifferentialOrange/gh-206-feature-discovery
branch
DifferentialOrange
added a commit
that referenced
this pull request
Nov 11, 2022
Graceful shutdown was introduced in Tarantool with [1]. A week later it was reworked with [2]. So the timeline is as follows. - Graceful shutdown is introduced, new feature flag is added and the protocol version is bumped to 4. - Graceful shutdown is reworked, feature flag is dropped and the protocol version is dropped to 3. - Next Tarantool version released. So the idea for users is "IPROTO_FEATURE_GRACEFUL_SHUTDOWN and protocol version 4 never existed". It also means that any new feature flag may have value `4` (same as IPROTO_FEATURE_GRACEFUL_SHUTDOWN), but with completely different meaning. IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag was added in [3] by mistake due to misunderstanding the event timeline. This patch removes the flag. Since `_features` dict is an internal of a connection object, the change shouldn't break anything for users. 1. tarantool/tarantool@6f29f9d 2. tarantool/tarantool@2e9cbec 3. #243 Closes #262
DifferentialOrange
added a commit
that referenced
this pull request
Nov 11, 2022
Graceful shutdown was introduced in Tarantool with [1]. A week later it was reworked with [2]. So the timeline is as follows. - Graceful shutdown is introduced, new feature flag is added and the protocol version is bumped to 4. - Graceful shutdown is reworked, feature flag is dropped and the protocol version is dropped to 3. - Next Tarantool version released. So the idea for users is "IPROTO_FEATURE_GRACEFUL_SHUTDOWN and protocol version 4 never existed". It also means that any new feature flag may have value `4` (same as IPROTO_FEATURE_GRACEFUL_SHUTDOWN), but with completely different meaning. IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag was added in [3] by mistake due to misunderstanding the event timeline. This patch removes the flag. Since `_features` dict is an internal of a connection object, the change shouldn't break anything for users. 1. tarantool/tarantool@6f29f9d 2. tarantool/tarantool@2e9cbec 3. #243 Closes #262
DifferentialOrange
added a commit
that referenced
this pull request
Nov 11, 2022
Graceful shutdown was introduced in Tarantool with [1]. A week later it was reworked with [2]. So the timeline is as follows. - Graceful shutdown is introduced, new feature flag is added and the protocol version is bumped to 4. - Graceful shutdown is reworked, feature flag is dropped and the protocol version is dropped to 3. - Next Tarantool version released. So the idea for users is "IPROTO_FEATURE_GRACEFUL_SHUTDOWN and protocol version 4 never existed". It also means that any new feature flag may have value `4` (same as IPROTO_FEATURE_GRACEFUL_SHUTDOWN), but with completely different meaning. IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag was added in [3] by mistake due to misunderstanding the event timeline. This patch removes the flag. Since `_features` dict is an internal of a connection object, the change shouldn't break anything for users. 1. tarantool/tarantool@6f29f9d 2. tarantool/tarantool@2e9cbec 3. #243 Closes #262
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
code-health: update request type constant name
Modern Tarantool documentation uses IPROTO_REQUEST_TYPE name for request type instead of IPROTO_CODE [1].
Part of #206
code-health: use hexadecimal codes for requests
Modern Tarantool documentation uses hexadecimal codes for request codes [1].
Part of #206
code-health: expose DatabaseError properties
Provide explicit handles to extract DatabaseError exceptions properties. Before this patch, one could extract Tarantool error code only through internal
argsproperty.Unfortunately, current exceptions API is inconsistent. Code uses
DatabaseError(code, message),NetworkError(message)andNetworkError(exc), while NetworkError is a child class of DatabaseError.This patch shouldn't break current behavior.
Part of #206
iproto: support feature discovery
Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send the schema version and supported features and receive server-side schema version and supported features information to tune its behavior.
After this patch, the request would be send on
connect. Connector will use protocol version that is minimal of connector version (now it's 4) and server version. Feature would be enabled if both client and server supports it (for now client does not support any features from the list). Unknown request type error response is expected for pre-2.10.0 versions. In this case, protocol version would beNoneand no features would be enabled.Closes #206